Authorization code grant 是 OAuth 規範當中最常見也最常用的授權方式，適用於 confidential client，也就是有受保護的後端的應用程式。

Roles

在上面這張示意圖中，有幾個主要的 roles:

• User - 使用者
• Browser - 使用者與應用程式的互動介面。這裡遇到的前端介面可以是 server-side 或是 client-side render
• Client - 使用者正在使用的應用程式，也是想要存取資源、但暫時未獲得授權的應用程式
• Authorization server - 協助授權的應用程式
• Resource server - 使用者存放資源的地方

Steps

1

使用者正在使用某應用程式 (Client) ，在某一個時間點，想要讓這個應用程式載入自己存放在另外一個地方 (Resource server) 的資源，譬如照片。

於是，使用者點擊了某個按鈕，譬如「連結我的照片」

2

這時 Client 就會將使用者轉 (redirect) 到 Authorization server，在送出請求的時候，同時挾帶著 Code challenge 和 Code challenge method

Code challenge 和 Code challenge method 是屬於 OAuth Proof Key for Code Exchange (PKCE) 流程的一部分，用來確保送出授權請求的 Client，和到時候獲得 token 的 Client 是同一方。我們之後再回頭來看 PKCE 的機制。

3

當 Authorization server 收到請求，便會將使用者導向登入頁面。這裡的登入頁面在 Authorization server，而不在 Client 或 Resource server 任何一方。

4

使用者看到登入頁面之後，就會輸入自己的帳號密碼，讓 Authorization server 進行驗證

5

當 Authorization server 確認使用者後，便會將使用找導回 (redirect) 到 Client，並同時在 URL 當中挾帶 authorization code

6

當 Client 收到來自 Authorization server 帶有 authorization code 的請求後，緊接著就會再次向 Authorization server 發出請求，並同時挾帶 authorization code 和 code verifier

這裡的 code verifier 也是 PKCE 的一部分

7

當 Authorization server 收到 authorization code 和 code verifier，確認該 Client 的身份之後，就會回傳 access token 和 refresh token

8

最後，拿到 access token 的 Client，就可以帶著這個 token 向 Resource server 送出資源的請求。而 Resource server 就會根據 access token 當中的權限設定，來決定是否要送出資源給 Client

這裡要注意的是，在 step 2 和 5 的部分，其行為是 "redirect" 而非 "api 請求"，因此在這兩個步驟當中所夾帶的資料會暴露在 url 當中。

這也是為什麼 Authorization server 不一開始就送出 access token，而是要送出先 authorization code 到 Client 前端後，再由後端發出 api 請求取得 access token。

另一方面，這個 authorization code 還是有被攔截的可能，也就是在 step 6 的時候，有另外一個應用程式攔截了 authorization code，取代原本的 Client 向 Authorization server 拿 token。這時 PKCE 的機制就發揮了作用。

由於後面這個應用程式不知道原本的 Client 在 step 2 的時候向 Authorization server 送出什麼 Code challenge 和 Code challenge method，所以如果在 step 6 隨便送出 Code verifier 的話，那麼 Authorization server 透過 Code challenge method 來計算，就會知道 Code challenge 和 Code verifier 並不相符。

明天繼續來看看其他的 OAuth grant type!